Add anonymous multi-user vote command - #191

The conditional UPDATE fixes the double publish, but it also makes closed = True durable before anything has actually been published. Everything after this point is best effort and outside the transaction, so there are a few ways the tallies go missing for good:

• _resolve_poll_channel returns None (channel deleted, permissions changed, transient 5xx on fetch_channel) and close_anonymous_vote just returns.
• Both the edit and the fallback send fail, which is the case your own log line calls unrecoverable.
• The bot restarts between this commit and the send. register_anonymous_vote_views filters on closed.is_(False), so nothing ever picks it back up.

The ballots are all still sitting in the table, so it is recoverable with SQL but not through the bot, which is the awkward part when a nomination vote people waited a week on comes back empty.

Could we split "voting is over" from "results are out"? A published_at column would let you claim the close exactly as you do here, then have register_anonymous_vote_views also sweep closed.is_(True) & published_at.is_(None) on startup and retry the publish. If that is too much for this PR, even a small /admin vote-results <session_id> that re-renders build_results_embed from the stored ballots would give us a way out without pulling in someone with database access.

Two things about refreshing on every ballot.

The first is the participation leak you already flagged in the description, but I think calling it a count undersells it. Because this fires the instant a ballot lands, it is a live feed rather than an aggregate. Anyone sitting in the channel sees a box appear next to a specific nominee at a specific second, and in a mod team of five or ten, matching that against who is online right then narrows it a long way. The approve/reject split staying hidden does not help much once you can tell who participated and when.

Second, per message edits are limited to roughly 5 per 5 seconds. If the team gets told "vote now" and a dozen people go at once, these edits queue behind the bucket and the ephemeral confirmations start lagging the clicks.

Batching this behind a short timer, or dropping the live boxes and only rendering counts at close, would deal with both at once.

_register_persistent_views runs from on_ready, which fires on every full gateway reconnect and not just at startup, so each reconnect adds another sleeping schedule() task for every open session. Your conditional UPDATE in _close_vote_session means only one of them can publish, so this is not a correctness problem anymore, but they do pile up for the lifetime of the vote and then all wake at the same moment and hit the database together.

On a 12 hour vote nobody would ever notice. With a 30 day ceiling it is a lot more visible. Keeping a set[int] of session ids already scheduled, or holding the tasks and cancelling the previous one before rescheduling, would be enough.

Worth saying register_ban_views has the same shape, so this is an existing pattern rather than something this PR invented. The long vote window is just what makes it show.

int(values[0]) is unguarded. Discord validates select values against the component it sent, so in practice this holds, but if it ever does not the failure mode is a ValueError raised after the defer has already gone out. The voter gets silence and we only find out from the logs.

interaction.data is typed dict | None as well, so (interaction.data or {}).get("values", []) covers both. A try/except ValueError falling through to the existing "Unknown nominee." path would be plenty.

display_name goes into the embed description unescaped, and embed descriptions do render masked links. A nominee whose nickname is something like [click](https://example.com) ends up as a live link inside a staff poll, and ** or a backtick in a nickname will quietly mangle the line.

Admins pick the nominees so the blast radius is small, but discord.utils.escape_markdown(candidate.display_name) here costs nothing. Same thought for wherever display_name reaches build_results_embed.

I went and checked this one because it is the sort of claim that is easy to get backwards, and it is right. MySQLDialect_asyncmy overrides _found_rows_client_flag to return CLIENT.FOUND_ROWS unconditionally, so the flag really is always set for our connection string and the documented 0 is unreachable. Good comment to have left behind.

One consequence worth knowing about: because a no-op update also reports 1, someone re-picking the choice they already had gets "Vote recorded" rather than "Vote updated". Harmless, just slightly odd if you spot it, and not worth a second round trip to fix.

This posts to whatever channel the command happened to be run in, with no allowlist and no confirmation step in front of it. One wrong channel and the nominee names, the live activity boxes and the final approve/reject tallies are all readable by everyone who can see that channel, nominees included.

For the CC program that feels like the worst possible version of a typo, since a rejected nominee would find out in public. Could we either pin the poll to a configured staff channel, or check ctx.channel.id against the relevant settings.channels entries before we get this far? Fine to leave as is if the intent is that the starter always picks deliberately, but right now nothing stops it.

The rollback above covers the send failing, which was the important half. There is still a window here though: if the bot dies between ctx.channel.send returning and this update committing, the poll is live in the channel while the row keeps message_id = NULL. On restart the session is picked up as open, and at close _edit_poll_with_results bails on if not message_id and posts results as a fresh message, leaving the original poll sitting there with controls that still look usable.

That degrades reasonably rather than breaking, so I would not hold the PR on it. Worth a short comment in the code though, so the next person does not read message_id as always populated for a poll that got posted.

Worst case this is 25 sequential round trips, which is exactly why you added the defer, so no correctness issue. Just noting that guild.query_members(user_ids=member_ids) does the same lookup in a single gateway call and caps at 100 ids, so it would collapse the loop and be gentler on the member endpoint if you feel like it.

Worth being precise in this docstring, because "never shown in Discord" is carrying a lot of weight. voter_id and choice sit next to each other in plain text under a unique constraint, so anyone with read access to the database or to a backup can reconstruct exactly who voted which way on every nominee.

I do not think that is avoidable when you need the pair to support changing a vote, and I am not asking for hashing here. My concern is the gap between this and what the poll embed tells voters ("Votes stay anonymous"). Anonymous from the mod team and anonymous from whoever holds the database are quite different promises, and the people casting these votes should probably be told which one they are getting before this goes live.